Don’t report missing fields in struct exprs with syntax errors.

…ebank

Don’t report missing fields in struct exprs with syntax errors.

@Noratrieb [told me](https://internals.rust-lang.org/t/custom-cargo-command-to-show-only-errors-avoid-setting-rustflags-every-time/24032/7?u=kpreid) that “it is a bug if this recovery causes follow-up errors that would not be there if the user fixed the first error.” So, here’s a contribution to hide a follow-up error that annoyed me recently.

Specifically, if the user writes a struct literal with a syntax error, such as

```rust
StructName { foo: 1 bar: 2 }
```

the compiler will no longer report that the field `bar` is missing in addition to the syntax error.

This is my first time attempting any change to the parser or AST; please let me know if there is a better way to do what I’ve done here. ~~The part I’m least happy with is the blast radius of adding another field to `hir::ExprKind::Struct`, but this seems to be in line with the style of the rest of the code. (If this were my own code, I would consider changing `hir::ExprKind::Struct` to a nested struct, the same way it is in `ast::ExprKind`.)~~ The additional information is now stored as an additional variant of `ast::StructRest` / `hir::StructTailExpr`.

**Note to reviewers:** I recommend reviewing each commit separately, and in the case of the first one with indentation changes ignored.

…ebank

Don’t report missing fields in struct exprs with syntax errors.

@Noratrieb [told me](https://internals.rust-lang.org/t/custom-cargo-command-to-show-only-errors-avoid-setting-rustflags-every-time/24032/7?u=kpreid) that “it is a bug if this recovery causes follow-up errors that would not be there if the user fixed the first error.” So, here’s a contribution to hide a follow-up error that annoyed me recently.

Specifically, if the user writes a struct literal with a syntax error, such as

```rust
StructName { foo: 1 bar: 2 }
```

the compiler will no longer report that the field `bar` is missing in addition to the syntax error.

This is my first time attempting any change to the parser or AST; please let me know if there is a better way to do what I’ve done here. ~~The part I’m least happy with is the blast radius of adding another field to `hir::ExprKind::Struct`, but this seems to be in line with the style of the rest of the code. (If this were my own code, I would consider changing `hir::ExprKind::Struct` to a nested struct, the same way it is in `ast::ExprKind`.)~~ The additional information is now stored as an additional variant of `ast::StructRest` / `hir::StructTailExpr`.

**Note to reviewers:** I recommend reviewing each commit separately, and in the case of the first one with indentation changes ignored.

…uwer

Rollup of 8 pull requests

Successful merges:

 - #151864 (Implement AST -> HIR generics propagation in delegation)
 - #152941 (prefer actual ABI-controling fields over target.abi when making ABI decisions)
 - #153227 (Don’t report missing fields in struct exprs with syntax errors.)
 - #152966 (Migrate 11 tests from tests/ui/issues to specific directories)
 - #153003 (rustdoc: make `--emit` and `--out-dir` mimic rustc)
 - #153034 (Remove unhelpful hint from trivial bound errors)
 - #153221 (Add release notes for 1.94.0)
 - #153297 (Update the name of the Hermit operating system)

…ebank

Don’t report missing fields in struct exprs with syntax errors.

@Noratrieb [told me](https://internals.rust-lang.org/t/custom-cargo-command-to-show-only-errors-avoid-setting-rustflags-every-time/24032/7?u=kpreid) that “it is a bug if this recovery causes follow-up errors that would not be there if the user fixed the first error.” So, here’s a contribution to hide a follow-up error that annoyed me recently.

Specifically, if the user writes a struct literal with a syntax error, such as

```rust
StructName { foo: 1 bar: 2 }
```

the compiler will no longer report that the field `bar` is missing in addition to the syntax error.

This is my first time attempting any change to the parser or AST; please let me know if there is a better way to do what I’ve done here. ~~The part I’m least happy with is the blast radius of adding another field to `hir::ExprKind::Struct`, but this seems to be in line with the style of the rest of the code. (If this were my own code, I would consider changing `hir::ExprKind::Struct` to a nested struct, the same way it is in `ast::ExprKind`.)~~ The additional information is now stored as an additional variant of `ast::StructRest` / `hir::StructTailExpr`.

**Note to reviewers:** I recommend reviewing each commit separately, and in the case of the first one with indentation changes ignored.

…uwer

Rollup of 12 pull requests

Successful merges:

 - #152941 (prefer actual ABI-controling fields over target.abi when making ABI decisions)
 - #153227 (Don’t report missing fields in struct exprs with syntax errors.)
 - #153265 (Clarified doc comments + added tests confirming current behavior for intersperse/intersperse_with)
 - #152966 (Migrate 11 tests from tests/ui/issues to specific directories)
 - #153003 (rustdoc: make `--emit` and `--out-dir` mimic rustc)
 - #153034 (Remove unhelpful hint from trivial bound errors)
 - #153152 (Migration of LintDiagnostic - part 5)
 - #153177 (disable the ptr_fragment_in_final test on s390x)
 - #153221 (Add release notes for 1.94.0)
 - #153279 (feat: Provide an '.item_kind()' method on ItemEnum)
 - #153297 (Update the name of the Hermit operating system)
 - #153309 (Cleanup of c-variadic link test)

Rollup merge of #153227 - kpreid:struct-missing-field, r=estebank

Don’t report missing fields in struct exprs with syntax errors.

@Noratrieb [told me](https://internals.rust-lang.org/t/custom-cargo-command-to-show-only-errors-avoid-setting-rustflags-every-time/24032/7?u=kpreid) that “it is a bug if this recovery causes follow-up errors that would not be there if the user fixed the first error.” So, here’s a contribution to hide a follow-up error that annoyed me recently.

Specifically, if the user writes a struct literal with a syntax error, such as

```rust
StructName { foo: 1 bar: 2 }
```

the compiler will no longer report that the field `bar` is missing in addition to the syntax error.

This is my first time attempting any change to the parser or AST; please let me know if there is a better way to do what I’ve done here. ~~The part I’m least happy with is the blast radius of adding another field to `hir::ExprKind::Struct`, but this seems to be in line with the style of the rest of the code. (If this were my own code, I would consider changing `hir::ExprKind::Struct` to a nested struct, the same way it is in `ast::ExprKind`.)~~ The additional information is now stored as an additional variant of `ast::StructRest` / `hir::StructTailExpr`.

**Note to reviewers:** I recommend reviewing each commit separately, and in the case of the first one with indentation changes ignored.

…t-syntax-error, r=dingxiangfei2009

fix(thir): Include `NoneWithError` in Enum Struct Tail Assertion

### Summary:

Fixes the ICE triggered when a syntax error appears inside an enum variant struct literal.

PR rust-lang#153227 added `StructTailExpr::NoneWithError` and updated the `match base` arm in the `AdtKind::Enum` branch of `thir/cx/expr.rs`, but overlooked the `assert!(matches!(...))` guard preceding it, which still only listed `None | DefaultFields(_)`.

Closes rust-lang#153390

r? @dingxiangfei2009
cc @matthiaskrgr

Rollup merge of #153394 - TKanX:bugfix/153390-ice-enum-struct-syntax-error, r=dingxiangfei2009

fix(thir): Include `NoneWithError` in Enum Struct Tail Assertion

### Summary:

Fixes the ICE triggered when a syntax error appears inside an enum variant struct literal.

PR #153227 added `StructTailExpr::NoneWithError` and updated the `match base` arm in the `AdtKind::Enum` branch of `thir/cx/expr.rs`, but overlooked the `assert!(matches!(...))` guard preceding it, which still only listed `None | DefaultFields(_)`.

Closes #153390

r? @dingxiangfei2009
cc @matthiaskrgr

…ebank

Don’t report missing fields in struct exprs with syntax errors.

@Noratrieb [told me](https://internals.rust-lang.org/t/custom-cargo-command-to-show-only-errors-avoid-setting-rustflags-every-time/24032/7?u=kpreid) that “it is a bug if this recovery causes follow-up errors that would not be there if the user fixed the first error.” So, here’s a contribution to hide a follow-up error that annoyed me recently.

Specifically, if the user writes a struct literal with a syntax error, such as

```rust
StructName { foo: 1 bar: 2 }
```

the compiler will no longer report that the field `bar` is missing in addition to the syntax error.

This is my first time attempting any change to the parser or AST; please let me know if there is a better way to do what I’ve done here. ~~The part I’m least happy with is the blast radius of adding another field to `hir::ExprKind::Struct`, but this seems to be in line with the style of the rest of the code. (If this were my own code, I would consider changing `hir::ExprKind::Struct` to a nested struct, the same way it is in `ast::ExprKind`.)~~ The additional information is now stored as an additional variant of `ast::StructRest` / `hir::StructTailExpr`.

**Note to reviewers:** I recommend reviewing each commit separately, and in the case of the first one with indentation changes ignored.

Fix ICEs due to incomplete typechecking on struct literals with syntax errors.

Fixes rust-lang#153388.
Followup to rust-lang#153227.

Today I have learned that when we don’t emit a diagnostic *specifically from typeck*, we need to call `self.infcx.set_tainted_by_errors()` to signal that the type checking is incomplete despite the lack of error.

r? fmease

Rollup merge of #153453 - kpreid:fix-153388, r=fmease,estebank

Fix ICEs due to incomplete typechecking on struct literals with syntax errors.

Fixes #153388.
Followup to #153227.

Today I have learned that when we don’t emit a diagnostic *specifically from typeck*, we need to call `self.infcx.set_tainted_by_errors()` to signal that the type checking is incomplete despite the lack of error.

r? fmease